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(54) Network address translation gateway 

(57) A network address translation gateway pro- 
vides nonnal network translation for IP datagrams 
traveling from a local area network using local IP ad- 
dresses to an external networK but suspends source 
service address (port) translation when the port is re- 
served for a specific protocol, such as the ISAKMP 
"handshaking" protocol that is part of the IPSec protocol 



model. ISAKMP exchanges require both source arxi tar- 
get computers to use the same service address (port). 
By provkling a network interface that does not translate 
the source service address (port), this gateway enables 
the initiation and maintenance of secure, encrypted 
transmissions using IPSec protocol between a local ar- 
ea network usirig k>cal IP addresses and servers on the 
internet 
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Descrtption 
BACKGROUND 

[0001] Virtual private networking (VPN) using TCP/IP 
enables secure, hi^ speed communications between 
remote computing sites, using the internet as a commu- 
nications medium. Information passirig between sites 
across the internet may be protected against intercep- 
tion by unwanted eavesdro^ers or maitdous hackers 
by a variety of security measures. Effective security 
measures must at a miriimum, incorporate functkins 
that ensure any or all of the foikTwtr^ protections: Data 
integrity against the inadvertent or malicious modHica- 
tiOT of data during transit; prevention against deniat-of- 
service attacks by em^oying antin'epeat measures; 
source authentk:ation; confidentiatity of souroe address 
and other header tnfbmnation during transit; and packet 
payload protection against unwanted interception. One 
standard model for providing intemet security is the In- 
ternet Protocol Security suite. IPSec. IPSec works with 
the TCP/IP communications protocol to provide secure 
communicatk^s between devk^es connected to the in- 
temet or connected to private LANs (Local Area Net- 
works) that are, themselves, connected to the internet 
[0002] The TCP/IP (Transmission Control Protocol/ 
Intemet Protocol) protocol suite uses IP addresses to 
identify each device on a network. A global IP address 
unkfuely identifies a device on the intemet Such devic- 
es may t>e computers, printers, routers, switches, gate- 
ways, or other network devices. Devices havir^ gk}bal 
IP addresses may be directly referenced as a source or 
destination on the Intemet. The TCP/IP communica- 
tions protocol, however, is not exdustvety limited to the 
intemet but may be used on private LANs as well. Pri- 
vate LANs using TCP/IP frequently use "tocal" IP ad- 
dresses for network devices. Although no two devices 
on a private LAN may share the same local IP address, 
private LANs are isolated from the internet and local 
devices on the LAH are not visit>le from the intemet IP 
addresses for local devices therefore need not be "gk>- 
bally" unique. A LAN using k>cal IP addresses will be 
connected to the Intemet through a gateway, which is a 
device that may fHter or route messages between the 
LAN and the intemet Since the gateway is directly at- 
tached to the intemet and is visible to it the gateway 
must have a globally unique IP address for communi- 
cating across the intemet However, since the LAN is 
not directly visible from the intemet kx^al machines on 
the LAN do not require IP addresses that are globally 
unique. 

[0003] TCP/IP is the communications protocol that is 
used on the intemet Infcmnation to be communicated 
using TCP/IP is contained in "datagrams." A datagram 
consists of a discrete "packer of information to which 
one or more headers are appended. Headers contain 
infomiation needed by TCP/IP to direct the packet to its 
intended destination and to ensure its proper handling 



durir^ transit Each datagram is indivlduafly addressa- 
ble, and may be a com^cti<»M)riented TCP dat^ram 
or a "connectk)n}ess" UDP (User Datagram Protocd) 
datagram. Eadh UDP datagram includes an IP header 

5 and a UDP hecKier. The IP header contains at least a 
"source" IP address arKJ a "destination" IP address, 
white the UDP header includes source and destiriation 
service addresses (port addresses, given as numbers). 
In IPv4, IP addresses are 32 bits in lertgth, and are as- 

10 sodated with the rKiw-famifiar xxx.xxx.xxx.xxx format 
In this format each three-digit segment is a t>inary octet 
representir^ a number betwe^ 0 and 255. A complete 
IP address combines the ackiress of a logical network 
or network segment with the address of a "node" (de- 

'5 vice) on the network. The address of the networic or net- 
work segm^t may encompass the first 3, 6, or 9 digits 
of the IP address. A devk:e on the network or network 
segment is identified by a node address that consists of 
those remaining digits that are not used in the network 

20 or networic segment address. 

[0004] The scarce and destinatk)n sennce addresses 
contained in a UDP header are 16-bit numbers, various- 
ly known as "pwts" or"sockets," whteh are used to direct 
the packet to an intended process that is active cm the 

25 sending or receiving devk:e. The term "port." or "port ad- 
dress," as used herein, refers to a servrce address fieki 
in a UDP header. Although in theory there are as many 
ports as there are addresses in a 1 6-t}tt numb^, by con- 
vention many port addresses have been reserved for 

30 established processes. Thus, for example, port 80 is re- 
served for HTTP, and ports 20 arxi 21 are res^ved for 
FTP Through the use of port addresses, data arriving 
at a local machine running more than one process will 
be directed to the process for which it was interxled. 

35 Where a process runrting on a kx:al host is not one of 
the reserved processes, the local host may select any 
port number from a pool of unreserved port numbers to 
identify the "source" process. A reply packet referendr^ 
that port numt>er in the '*destinatk)n" field will be directed 

^ to the process. 

[0005] With the explosive growth of intemet usage 
during the last decade, and its projected growth in the 
future. gk>bally unique IP addresses have beccnne a 
scarce resource. In addition, many businesses mairv 

<5 taining private LANs have little or no need for each com- 
puter and device on the LAN to have a unk^ gk>t)al IP 
address. Many such businesses wouki, in any event 
prefer to maintain the confkientiality of their computers' 
IP addresses. Rather than waste limited global resourc- 

50 es t>y giving each k>cal device a unk^ue glot>al IP ad- 
dress, many private LANs utilize kx:al IP addresses for 
devices on the IAN. In order to provide connectivity to 
the intemet such LANs will employ a single gbbalty 
unique address to be used on the intemet by the gate- 

55 way separating the LAN from the intemet 

[0000] Through the use of Netw<^ Address Transla- 
ti(Ki (NAT) techniques, a gateway device separatirtg a 
LAN from the intemet can provide security as a firewall 



3 



EP1 130 846 A2 



4 



while enabling machines with local IP addresses to ac- 
cess the internet through the unique gtobal address of 
the gateway. A device on a LAN may have a static local 
IP address, or it may have a local IP address dynamo 
cally assigned to it at log on. The gateway maintains a 
translation tatile with the local 1 P addresses for each de- 
vice on the LAN. A UDP packet sent from a local ma- 
chine and destined for the internet will have its local IP 
address and port address identified in the source fields 
of the IP and UDP headers, respectively. The gateway 
will receive the packet from the tocal machine, wiO sut>- 
stitute its external globalty-unk^ue IP address and a new 
port address (taken from a pool of unused, unreserved 
port addresses) into the source fields of the IP and UDP 
headers. It will next update the CRC (Cyclical Redun- 
dancy Check) and make any oth^ necessary changes 
to ensure data integrity, then will send the packet to the 
internet As part of the process, the gateway will update 
Its internal translatton table to cross reference the local 
machine's IP address with the source port address orig- 
inally reported by that machine, with the new source port 
address assigned to the internet-bound packet, and with 
the destination IP address. Upon recept of a r^y from 
the tntemet, the gateway will recognize its own IP ad- 
dress in the packet header, and will examine the incom- 
ing packet's destination port address. If it finds the des- 
tinatkxi port address in its Internal table, the gateway 
will substitute the cross refererrced k)cal machine's IP 
address and original port address into the destination 
fiekls of the packet, will update the CRC and any other 
necessary parameters, and then will dispatch the packet 
to the LAN, v^ere it will be received by the kx:al machine 
and directed to the appropriate process. In this manner, 
a numljer of computers on a LAN having only local IP 
addresses can communicate across the Internet 
through a single glot>aity unique IP address. 
[0007] Although NAT gateways provide firewall secu- 
rity against direct accessing of the LAN from the internet, 
they do not provide security against interceptkin or mod- 
ification of a packet intended for the LAN while in transit 
on the internet, and they do not ensure Trustworthiness" 
from challenges originating within the LAN. Thus, the 
security provkied by IPSec is a necessary protection for 
LANs that must maintain security while interfacing with 
the internet 

[0008] A common implementatk}n of IPSec is to pro- 
vide security for VPNs consisting of at least one main 
computing site and one or more remote LANs. The main 
site and remote LANs are connected across the intemet, 
using that high speed medium to communicate between 
sites instead of significantly more expensive private 
leased lines. The drawfc>ack to using the intemet as a 
transmission medium, however, is that the intemet is in- 
herently insecure, and provides little or no inherent pro- 
tection against the srK>oping, detection, "spoofing," or 
ultimate theft, modificatkjn or diversk>n of messages by 
hackers. Thus, there Is a need fw comprehensive se- 
curity measures wh^e secure data transmissions are 



required. The IPSec protocd implements security 
measures to erasure authenticatk)n of data and data ir>- 
tegrity. 

[0009] The IPSec protocol suite implements security 

5 at the network layer of the multilayered OSI (Open Sys- 
tems Interconnectkm) network reference model. The 
suite includes a number of s^rate protocols that are 
used in conjunction with one another to ensure the se- 
curity of UDP datagrams that carry irrformatk>n across 

10 the intemet The base architecture of IPSec compliant 
systems is explained in RFC2401 , "Security Architec- 
ture for the Intemet Protocol." S. Kent and R. Atkinson 
(November 1 998). The AH (Authentfcatfon Header) pro- 
tocol assures data integrity, source authenttcatran, and 

IS incorporates "anti-repear measures to deter denial-of- 
sennce attacks. ESP (Encapsulation Security Payload) 
protocol provides protections simitar to AH. but adds the 
additkxia] feature of payload erKTyptkxi. Both AH and 
ESP headers have a fteld fcr a Security Parameters In- 

20 dex (SPl). The SPI is a 32-bit pseudo-random value that 
is used to identify a Security Assodatkxi (SA) for the 
datagram. Further infonnatwn regarding these proto- 
cols may be found in RFC1826, "IP Authentkation 
Header," by R Atkinson (August 1995), and RFC2406, 

25 "IP Encapsulating Security Payload (ESP)." S. Kent and 
R. Atkinson (November 1998). ISAKMP/Oakley (Inter- 
net Security Assodatton and Key Management Proto- 
col, also commonly refemed to as Intemet Key Ex- 
change - IKE) is a handshaking protocol that estabTishes 

30 the parameters for a secure sesskm between two hosts 
and provides for the exchange of keying and other se- 
curity information that is used to implement the secure 
sessk>n and permit the transmission of encrypted data. 
The ISAKMP/Oakley protocol (hereafter refen-ed to sim- 

35 ply as ISAKMP) involves the initial exchanges of unen- 
crypted messages to provide both machines with initia>- 
izatkxi data from which authentk^ation may be estab- 
lished and secure keys for data encryptran may be gen- 
erated. An explanatbn of these processes may be found 

40 in RFC2409. The Intemet Key Exchange." D. Harkins 
and D. Carrel (November, 1998). Once security param- 
eters sufficient estat)lish Security Assodaljons (SAs) 
tDetween hosts have been exchanged, all sub>sequent 
transmissions will be encrypted and fully authenticated 

45 in accordance with the agreed-upon protocols. At that 
point the ISAKMP protocol terminates. Subsequent ad- 
dressirig is based upon the IP address for each machine 
and the machine's SPI for that session. The SPl is 
unique for each machine during a sessk)n. The gateway 

50 for a private LAN will maintain an internal table in which 
"SPMn" in a value that is cross referenced to the local 
machine's IP address, and "SPI-ouT is cross referenced 
to the IP address of the machine on the intemet that is 
communicating with the local machine. The SPI for each 

55 machine is computed from informatton exchanged dur- 
ing the ISAKMP transmissicms. and is carried in the AH 
or ESP header that is appended to UDP packets. Be- 
cause IPSec protocols may be nested to provide secu- 
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rity in a variety of environments, a single datagram may 
include both an AH and an ESP header, and may en- 
crypt some header information. 
(001 0] Each of the foregoing security protocols mod- 
ifies the UDP padcet by placing new header information 
on the packet, mocfifying certain fields within the packet 
to oonfonn to the (Kotocot being used and, in some cas- 
es, enoypting the payload and an or parts of other pack- 
et headers. Thus, under IPSec, when a UDP datagram 
leaves a "secure" domain for transit ^;ross an untrusted 
network, it will normally consist of an IP header, an AH 
or ESP header (or both), and an encapsulated payk>ad. 
Header informatran will include a destination address, 
an SPI, and suffident SA infbrmaticm to ensure that the 
datagram reaches its destination and can be authenti- 
cated to the destination host Encapsulatksn of the pay- 
toad ensures that Information contained within the pay- 
toad is denied to unwanted eavesdrc^pers arxi hackers. 
The initial destination host for the datagram may be a 
router, gateway, or ftrewall between a LAN and the in- 
ternet. Upon arrival at the device on the border between 
the LAN and the internet the datagram may be opened, 
examined or decrypted in whole or In part, analyzed for 
further address infomnatwn, and routed to a kx:al IP ad- 
dress on the LAN. 

[0011] The ISAKMP handshaking protocol used in 
IPSec requires that both hosts intending to establish a 
secure sesswn between them use a process-specific 
port address (Port 500) for initial message exchanges. 
For this reason, Port 500 has been assigned for exclu- 
sive use with the ISAKMP protocol. By conventton, com- 
puters attempting to negotiate secure communk^ticxYs 
parameters by empbying the ISAKMP protocol must 
communicate strkrtty through each computer's Port 500. 
That is, ISAKMP messages from either computer must 
identify Port 500 as both the source and destinatton port 
addresses. If either computer receives a packet in whkh 
Port 500 is not specified as being both the source and 
destination, the packet will be discarded. 
[0012] While this protocol provides assurance that 
two hosts are communk^ating with each other, it be- 
comes unworkable when one host is located on a LAN 
that uses kx:al IP addresses and a NAT gateway. For 
example, Host A, having a local IP address on a remote 
L^N protected by a NAT gateway, wishes to establish a 
secure sessk}n with Host B, located at a main offk:e 
computing site. Host A would initiate the protocol by 
sending an unencrypted UDP datagram to Host B, giv- 
ing the "destinatkm" as Host B*s IP address, and the 
destinatkHi port address as "Port 5CX)." However, when 
the datagram reaches the NAT gateway connectirYg the 
remote LAN to the int^et the gateway will translate 
the destination port address to an arbitrary port numtser. 
Upon the anival of the datagram at Host B, the ISAKMP 
protocol will not be recognized, and Host B will rK}t re- 
spond. The computers will fail to establish a secure ses- 
sion. Because of this difficulty, it has heretofore been 
believed that the ISAKMP protocol canrtot be used to 



estabGsh a VPN using a NAT gateway where each com- 
puter <m the remote LAN uses a local rather than a glo- 
bal IP ^dress. 

[001 3] It is therefore an object of this inventran to pro- 
5 vide a gateway that will permit the use of ISAKMP pro- 
tocol authentrcation and key exchanges l}etween a com- 
puter having a non-global IP address and a host com- 
puter, usir^ the internet as a transmisstcm medium. 
[0014] It is a further o^ect of this invention to provide 
10 a gateway that will alk>w any number of computers on 
a private LAN using k>cal IP addresses to initiate or re- 
ceive messages via the intemet using ISAKMP protocol. 
[0015] It is another object of this inventton to provide 
a method for employing virtual private networking be- 
15 tween two or more LAN sites on the intemet, using 
ISAKMP protocol to initiate secure communications. 
[0016] These and oth^ objects of the invention will 
become apparent throughout the following descriptkxi. 

20 SUMMARY OF THE INVENTION 

[0017] In accordance with the present invention, a 
computer using a k>cal IP address on a remote LAN at- 
tached to an external network such as the intemet 

25 through a NAT gateway will use the I SAKMP protocol to 
exchange keys and establish SAs that will support a se- 
cure sesswn under IPSec. For norvl SAKMP tnaffic, the 
gateway performs address translatk)n as normal. How- 
ever, whenever a machtrie on the LAN originates an 

30 ISAKMP protocol message, the gateway will identify the 
datagram containing port addresses of Port 500. Upon 
encountering such a datagram, the gateway will trans- 
late the source IP address, but will not trar^slate the 
source port address, leaving it at Port 500, and will dis- 

35 patch the packet to the intemet with Port 500 designated 
as both the source and destination port addresses. The 
gateway will also update its internal tat)(e to "tMnd* Port 
500 to the local IP address and associate that binding 
with the external IP address of ttie destination machine 

^ for a predetermined length of time. If a valid reply is not 
received within tiie predetermined length of time, the 
"binding" between Port 500 and the kxal I P address will 
be released. This feature is necessary to ensure that 
Port 500 is not tied-up indefinitely, such as. for example, 

45 in a situation in which an ISAKMP protocol transmission 
has been initiated to an iricorrect destination IP address. 
Under those corKiitions, the gateway woukJ never re- 
ceive a vaiki reply. If there were no timer to release Port 
500 after a period during whk:h a valkJ reply is not re- 

50 ceived, the port woukJ r^ain txxind to the local IP ad- 
dress until the gateway was reset For most conditions, 
a perkxi of two seconds shouki be a suffident length of 
time to maintain the binding between Port 500 and the 
k>cal IP address while awaiting a valid reply. 

55 [0018] Durirtg the time that Port 500 is bound to a local 
JP address, the gateway will continue normal datagram 
prooesstng of datagrams not having Port 500 port ad- 
dresses while awaiting a valkj reply. A valkJ reply will be 
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a datagram having a source IP address that ts the same 
as the external IP address t^t is associated with Port 
500. and will have both the source and destination port 
addresses as Port 500. While awaitirig a valid reply, the 
gateway will ignore otho- UDP datagrams from the ex- 5 
temal network having Port 500 source and destination 
port addresses. t>ut not the proper source IP address. 
Also, while Port 500 Is bound to a local IP address, da- 
tagrams received from the LAN having source and des- 
tination port addresses of Port 500 will undergo "normal" 10 
address translation in which the Port 500 source port 
address will be translated to an arbitrary, unused port 
address before being sent to the external network. Be- 
cause such a datagram does not have both a source 
anddestinationportaddressof Port500, itisnotavalki is 
ISAKMP datagram, and will be ignored upon reaching 
Its IP destination. If the period of binding Port 500 to a 
local IP address should expire without a vaiki datagram 
having t>een received by the gateway, the bindir^g will 
be released, and Port 500 will become available for use ?o 
by the next datagram having a Port 500 source and des- 
tinatktn port address. 

[0019] While Port 500 is bound, upon receiving a valid 
reply datagram having source and destination port ad- 
dresses of Port 500 and the correct source IP address, 25 
the gateway will process the datagram by substituting 
the IP address of the local machine into the datagram 
header's destinatkxi IP address field, then will pass the 
datagram through to the LAN for delivery to the local 
machirie. When the datagram leaves the gateway, the 30 
gateway will release the t>inding t}etween the local IP 
address and Port 500, and wiH resume normal datagram 
processing. 

[0020] If a reply having the proper source IP address 
and port addresses of Port 500 is not received from the 35 
external network, the gateway will lime-out after a short 
predetermined ler)gth of time. If the gateway shouki 
time-out before a valkJ reply is received, that ISAKMP 
message exchange cannot be completed, but must be 
re-initiated. ^ 
[0021] Once the ISAKMP protocol has been complet- 
ed, and an encrypted secure session is under way, the 
gateway will perfomn local address translations by ref- 
erencing the SPI in the ESP header of incoming and out- 
going datagrams. The gateway wHI also ensure that 
each packet type (type 50 for an ESP packet) is correct 
for the datagram toeing passed through the gateway. Oc- 
casionally, a secure sesskm across a VPN will be inter- 
rupted, or a new session started. The gateway's first ir>- 
dicatron of this will be its receipt of a type 50 datagram so 
in which the IP addresses are recognized but the SP! 
associated with the destinatk>n does not appear in its 
internal table. When this happens, the gateway will dis- 
patch the datagram to the destinatk>n IP address using 
the new SPI, and will also set the destination SPI value ss 
(SPl-in or SPI-out, depending upon the direction of the 
transmission) in its table to the new value, and the 
source's SPI value to zero. Upon receiving a reply to the 



transmission, the gateway wiH rej^ace the zero in the 
SPI fiekl table with the new SPI for the destination IP 
address. 

[0022] Because the gateway ofthis invention does not 
encrypt or decrypt messages, but simply passes the 
payload (whrch may be encrypted or unencrypted) 
through to the LAN or to the internet for processing at 
the receiving machine, it does rKit require intensive 
processirig functionality, and may be used for private 
LANs in whrch expense and simpfk% of setup and 
maintenance are consideratk)ns. 

A BRIEF DESCRIPTION OF THE DRAWINGS 

[0023] Further ot^ects and advantages of the present 
invention can be found In the detailed descriptran of the 
prefierred embodiment when taken in conjunctk3n with 
the accompanying drawing in which: 

Rgure 1 depicts a virtud private network in whk:h a 
remote LAN usir^g k>ca] IP addresses is networked 
with a main computing site via an external network 
which may be the internet The LAN is connected 
to the external network through a NAT gateway. 
Rgure 2 depicts a dectskm chart used by the gate- 
way of this inventbn to process UDP datagrams re- 
ceived from the LAN for transmisston to the intennet. 
Rgure 3 depicts a decision chart of steps used by 
the gateway of this invention to process UDP data- 
grams received from the internet for delivery to a 
device on the LAN. 

Rgure 4 is provided for reference in foltowing the 
charts shown in Rgures 5, 6 and 7. Rgure 4 is a 
table containing IP addresses of local machines on 
a LAN (L-1 through L-3), the internal and external 
IP addresses of a gateway, and the IP addresses of 
external devices ("targets" T-1 through T-3) on an 
external network. 

Rgures 5a - 5c show representative fieWs firom an 
Internal table of the gateway cross referencing focal 
IP addresses of machines on a LAN (L-1 , L-2, ... L- 
x) and external IP addresses of external devrces (T- 
1 through T-3) with SPIs (security parameter index- 
es) used to authenticate encrypted datagrams. SPI- 
out represents the SPI of an encrypted datagram 
leaving the gateway for a device on the internet, 
while SPl-in represents the SPI of an encrypted da- 
tagram destined for a local machine on the LAN. 
Each view of the table, a, b and c. reflects header 
values for source, destinatbn, and SPI at different 
points in time. The changing values signify the com- 
mencement of a new sessk>n by one a local ma- 
chine with a target machine. 
Rgure 6 shows representative fiekis in datagram 
headers being exchanged between a single local 
machine and a single device on the extOTal net- 
work. Header values are modified through process- 
ing by the gateway of this invention. 
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Rgure 7 ^ows representative fields in datagram 
headers being exchanged between three local ma- 
chines (L-1 through L-3) on a LAN, and three targets 
(T-1 through T-3) on an external network? as Ihey 
are modified through processing by the gateway of 
this invention. 

Rgure 8 is a sdiematic diagram of signals passing 
between the datagram processirig function and the 
timer. 

DETAILED DESCRIPTION OF THE DRAWINGS 

[0024] In Figure 1 , a virtual private networl? (VPN) is 
shown in which a private local area network (LAN) 10 is 
connected to a computirig site 30 kx:ated on the irrtemet 
50. The LAN 10 uses local IP addresses, and is cor>- 
nected to the internet through the network address 
translation (NAT) gateway of this invention 20 . The 
computing site 30 may be a business headquarters, or 
one of any number of private LANs used by a muttina- 
tionat corporatktfi. an educationa) facility, or any other 
site which will be frequently accessed from remote lo- 
cations. Such sites will normatly have a firewall or gate- 
way 35 capable of running encryptron and other security 
applications. Such a gateway will have the ability to 
open a packet, decrypt or otherwise access its contents, 
and perform address translation, routing, de-encapsu- 
latk}n, and data manipulatkm functions as well. While 
such devices are able to support ISAKMP and other 
IPSec protocols, they do so by opening and decrypting 
packets, and manipulating data, and are, by and large, 
too expensive and powerful to be employed effidentty 
at remote LAN sites needing to establish a VPN with the 
main computing site. 

[0025] A server 40 at the main site runs the VPN serv- 
er software. Computers 15 at remote sKes each run ap- 
propriate VPN dienl software that implements IPSec se- 
curity protocols on each computer. 
[0026] A computer 15 on the LAN 10 wifl communi- 
cate with devk:es on or across the internet through gate- 
way 20 by sending an IP datagram to a server 40 at the 
computing site 30. 

[0027] Datagrams received at the gateway 20 are 
processed according to the dedsi(Ki charts shown in 
Rgures 2 and 3. Although the flow charts of Figures 2 
and 3 show both the processing steps and a sequence 
for the steps, the order for perfonming some of the func- 
tions is rtot critical, and s<^e of the steps may be done 
in an order other than is shown in the fiow charts without 
affecting the ultimate result For example. Rgures 2 and 
3 show that the first step after a datagram is received 
by the gateway is to determine the datagram type, while 
the last st^ is to perfonn the IP address translation that 
is necessary before the datagram is passed through the 
gateway. Some embodiments, however, could place the 
step of address trar^latk)n to some poirrt eariier in the 
process, and Vhts would not affect the outcome of the 
process. Slnoe the order of translating the IP address is 



not critical to the overall process, the determinatkin of 
when this translatkm should be done is a matter of erv 
gineering choice. 

[0028] As shown in Rgure 2, upon receiving a data- 

5 gram from the LAN, the gateway will check to see wheth- 
er the datagram is encrypted. It will do so tiy checking 
the 'Next Heade* field in the IP header to determine the 
type of datagram it is dealing with, and to see wfiether 
the datagram has been encrypted. A datagram type of 

10 50 (ESP) indicates that the datagram is encrypted, and 
port adchBss information may not be available. 
[0029] Continuing through the decision tree of Rgure 
2, if the datagram is encrypted, the gateway will check 
the datagram's S PI to see whether it appears in the SR- 

15 out field of the gatewa/s internal table. Representative 
fiekis from such a tat>le are shown in Rgures 5a - 5c. If 
the SPI of the datagram is found in the SPI^ut fiekl of 
the internal table, the gateway will modify the source IP 
address of the datagram to t)e the external IP address 

20 of the gateway, arKi wilt send the datagram to the exter- 
nal network for delivery to an ext^al device. 
[0030] If the datagram is encrypted, but the SPI does 
not appear in the gateway's internal tat>le, then accord- 
ing to the dectskm chart of Rgure 2 the gateway will as- 

25 sume that the datagram is initiating a new sessk)n. In 
this case the gateway will set the SPMn fieki of its inter- 
nal table to zero (0) and will set SPI-out to the new SPI 
from the datagram. These modifrcatkins to the internal 
table are reflected in Rgures 5a and 5b, in which a **new" 

30 SPI ('14662*). whk:h did not appear in the SPl-out field 
of the gateway's internal table in Rgure 5a, is shown as 
having been entered into the SPI-out fiekl, and SPI-in 
has been set to zero (0) in Rgure 5b. The encrypted 
datagram will then be sent to the external gateway after 

35 the source IP address has been translated from that of 
the k}cal devk:e to the external IP address of the gate- 
way. These steps are shown in Rgures 5b and 5c 
[0031] Continuir^ with the dectsk)n chart of Rgure 2, 
if the datagram is not erxrrypted, the gateway will next 

^ check the datagram's destination port address. If the 
port address is anything but Port 500, the gateway will 
^ter the source port address into its intemal table, 
cross reference it with the (local) source I P address, and 
wHI then substitute an arbitrary, unused port address into 

^ thesourceportaddressfieklof the IP header. It will also 
enter the new port address In its intemal tattle, again 
cross referenced to the (kx:al) source IP address. This 
process, whk^ is used for unencrypted datagrams not 
having Port 5(K} as a pori address, shall be referred to 

50 as "normal address translation'' for datagrams originat- 
ing on the LAN. These trar^ttons are shown in Rgure 
6, rows 1 and 2. The datagram will then be dispatched 
to the internet for routing to the destination IP address. 
[0032] In Rgure 2. where an incoming datagram's 

55 source and destirtaUon port addresses are Port 500, the 
gateway must next check its tables to see whether Port 
500 is already bound to an IP address. If Port 500 is 
free, then the gateway win "bind" Port 500 to the (local) 
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source IP address of the datagram, will create an asso- 
ciation between the port and the (ext^ai) destination 
IP address, and will send a signal to start the internal 
timer. The gateway will also process the datagram by 
sut)stituting the gateway's external IP address for the 
local IP address in the source IP address field. It wilt not, 
however, translate the source port address. By sus- 
pending the "normai" translattOT of the source port ad- 
dress, the gateway ensures that the target machine will 
be able to recognize the datagram as being an ISAKMP 
datagram. These steps are also shown in Rgure 6. rows 
5 and 6. 

[0033] In Figure 2, if an incoming datagram from the 
LAN has a source and destination port address of Port 
500, but Port 500 is already t»ound to some other local 
IP address, then the gateway cannot bind Port 5(X} for 
the message then being processed. In that event, the 
gateway will process the datagram "normally," as if it 
were not an ISAKMP datagram. That is, it will translate 
the datagram's source port address to an artxtrary 
numt)er and will translate the source IP address to be 
that of the gateway's external IP address. The gateway 
will then send the datagram to the internet where it will 
be rejected by the target t}ecause it does not conform 
lo an ISAKMP datagram. This event is depicted in Rg- 
ure 7 at rows 1 5 and 1 6. 

[0034] In figure 3, a decision chart is shown which out- 
lines the steps the gateway will follow in processing da- 
tagrams received from the intemet Upon receiving a da- 
tagram, the gateway will first check its type and, if the 
datagram is encrypted, will check to see whether the SPl 
appears in its internal tat>le. If the SPl is recognized, its 
destination IP address will be translated to be the IP ad- 
dress of the local devk^e, and the datagram wilt be 
passed to the LAN for delivery to the local device, ff the 
SPl is noi recognized, the gateway will next check to 
see whether its SPMn fiekJ corresponding to the data- 
gram's source IP address is zero (0). If SPl-in is zero, 
the gateway will assume that the datagram is the first 
reply of a new sessk>n and will replace the zero in the 
SPMn fiekl with the SPl of the datagram. The gateway 
will then translate the destinatk)n IP address to be the 
local IP address of the device on the LAN, and will send 
the datagram to the LAN for delivery. This ev^t is 
shown in Figures 5b and 6c. In Rgure 5b. the SPl-in for 
local machine L-1 has been set to zero. Upon the gate- 
wa/s receipt of a datagram from the intemet having an 
SPl of 3288. the gateway wiU not find that SPl in its SPl- 
in field. The gateway will next check to see whether the 
SPWn field is holding a value of zero. Upon determining 
that SPl-in for local machine L-1 is zero, the gateway 
will replace the zero the SPl of the datagram 
("3288") and will send the datagram to the LAN. This is 
shown in Figure 5c. 

[0035] In Rgure 3. if the datagram from the intemet is 
not encrypted, the gateway will check to see virhether it 
has a pon address of 500. If it does not, the datagram 
will undergo "normaT address translation for datagrams 



from the external netwmk, mearvr^ that the local port 
address and kx:ai IP address of the devk» on the LAN 
wQt be substituted into the destination ftekis of the dat- 
agram, and the datagram wilt be s^t to the LAN for de- 

5 livery. This "normal" address translatton for datagrams 
from the intemet is shown in Rgure 6 at 17 rows 3 arwJ 4. 
[0036] 18 Again referring to Figure 3, If the datagram 
does have a port address of 500. the 1 9 gateway must 
next check to see whether Port 500 is bound to a local 

10 IP address and is 20 associated with the datagram's (ex- 
ternal) source IP address. If it is, then the datagram Is 
21 valki, and will be passed to the LAN after the desti- 
natfon IP address has been translated 22 from that of 
the external gateway to the IP address of the local de- 

15 vice. Upon passing the datagram to the LAN. the gate- 
way will release Port 500. This event is illustrated in Ftg- 
ure 6 at rows 7 and 8. 

[0037] If, in Rgure 3. Port 500 is bound to a focal IP 
address, and is associated with an external IP address 

20 other than that found in the source IP address of the 
datagram, then the datagram is not valid and will noi be 
further processed by the gateway. This event may be 
seen in Rgure 7 at rows 25- 31. At rows 25 and 26, local 
machine L-1 sends an ISAKMP datagram to target T-1 . 

25 At this point Port 500 is bound to the 1 P address of local 
machine L-1 and is associated with the IP address of 
target T-1 . However, as shown in Figure 7, the timer 
"times" out t)efore a reply is received at the gateway 
from T-1, and, at row 27, Port 500 is released. At rows 

30 28 and 29. local machine L-3 sends an ISAKMP data- 
gram to target T-3, binding Port 500 to L-3's IP address 
and creating an assodatfon with T-3's IP address. While 
Port 500 is bound, a repty is received from T-1 . However, 
because Port 500 is bound, and is associated with T-3*s 

35 IP address, the reply from T-1 is discarded. This Is 
shown at rows 30 and 31 of Rgure 7. 
[0038] Rgures 5a - 5c depkrt an internal table of the 
gateway in which the IP addresses and SPl numbers for 
encrypted oommunfoations between focal computers 

^ and targets on the intemet are maintained. Relds for "L- 
1." "L-2,'' "L-x," and "T-1" through •T-3" are induded for 
ease of reference, and do not appear in the gateway's 
internal tables. In Figure 5, the field "SPI-ouf holds the 
SPl for each target machine during a secure session 

45 with a specific computer on the LAN. The "SPMn" fiekJ 
gives the corresponding SPl that will be recognized by 
the focal computer as signifying a vaikl datagram intend- 
ed for it Figure 5a shows the table at a beginning time. 
Eight (8) focal computers have partidpated in encrypted 

50 sessfons with three targets, T-1 through T-3 during the 
life of the latrfe's data. This is shown by the fact that each 
focal machine shows an SPl-in assodated with its I P ad- 
dress. Although only three targets are shown in the ta- 
ble, it may be noted that each target is using a different 

55 SPI-outfor communicattons with each focal machine. In 
this manner, a target will know from which source an 
encrypted datagram was generated. 
[0039] Rgure 5b shows the same local and target 
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cofTifwtws as Rgure 5a. Here, however, the SPI-out for 
the sesskm betvveen L-1 and T-1 is a new SPl. tn<&;ating 
a new session between the computers. The gatewa/s 
first indication that a new session is taking place is its 
receipt of an encrypted datagram from the LAN having 
an SPI - "14662" - that is not in its table. The gateway 
forwards the datagram to the internet, but also modifies 
its tat)le to place the new SPI in the SPI-out field asso- 
ciated with the source and destination IP addresses for 
that datagram. It also places a zero in the SPMn field 
as a marker to indicate that a new SPIn'n is also expect- 
ed. Rgure 5c shows that a new SPI - "3288" - was in- 
cluded in a datagram received from T-1 . That SPI has 
been entered into the gatewa/s SPMn field, and fiirth©- 
communications between L-1 and T-1 during this ses- 
sion will use those SPPs to authenticate their messages. 
[0040] Rgure 6 charts the fkw of representative dat- 
agrams through the gateway of this invention by a single 
computer on a LAN communicating with a remote target 
on the internet Each row of the chart represents infor- 
mation in a datagram at either the LAN interface with 
the gateway or the internet interface with the gateway 
Consecutive rows represent data entering the gateway 
fix>m one side and leaving the gateway at the other. The 
gateway has one IP address, which may be a local IP 
address, at its interface with the LAN. and a global IP 
address at its interface with the internet. The columns 
in Rgure 6 depict the side of the gateway the datagram 
is traversing, the type of datagram, the datagram's 
source IP address and port address, the datagram's 
destination IP address and port address, and the data- 
gram's Security Parameter Index (SPI) for encrypted da- 
tagrams of type 50. using ESP (Encapsulated Security 
Payioad) protocol. 

[0041] Row 1 of Rgure 6 shows a UDP datagram ar- 
riving at the local interface of the gateway, and having 
a source IP address corresponding to local computer L- 
1, and a destination IP address of the target on the in- 
ternet, T-1 . For ease of reading, Rgure 4 provides a ta- 
ble of IP addresses cross referenced with local desig- 
nations L-1 through L-3. and target designations T-1 
through T-3. The source port address for L-1 is Port 
6404, and the target's destination port is Port 80. Since 
the datagram is not encrypted, and does not exhrt^ a 
port number of 500, it undergoes a normal translation in 
which an "arbitrary" port address, Port 10425 is substi- 
tuted into the source port address field and the gate- 
way's external IP address is substituted for tfie source 
IP address of the datagram. Although the translated 
source port address is said to be "artsitrary," it will nor- 
mally be the next in a sequernre taken from a pool of 
unreserved and presentiy unused port addresses main- 
tained by the gateway. 

[0042] As the datagram exits the gateway, as shown 
Rgure 6. in row 2. the address translation functk>n of the 
gateway has substituted the gateway's external IP ad- 
dress into the datagram header for tiie source IP ad- 
dress, and has giv^ the source port an arbitrary 



number. Rows 3 and 4 show the reply datagram from 
the target In row 3. a UDP datagram from the target 
shows the destination IP address as being the external 
IP address of the gateway, and a destination port as be- 
5 ing the pc^ address arbitrarily assigned by the gateway. 
Since the datagram is not erK:rypted and does not have 
a port address of 500, the datagram undergoes normal 
translation of the destination port address and IP ad- 
dress, then is sent to the LAN. In row 4. the gateway has 
10 substituted the kx:at computer's kKal IP address and 
port adress in the destination fields of the header before 
sending the datagram to the LAN. 
[0043] In row 5 of Rgure 6. the bcal computer initiates 
an ISAKMP protocol with the target The datagram type 
IS is shown as ISAKMP. Both the source and destination 
port addresses are Port 500. When the gateway deter- 
mines that the destination pcvt address is Port 500. it 
checks to see whether Port 500 is currently bound to 
any IP address. Since it is noL the gateway passes the 
20 datagram, translating only the source IP address field 
to show the gateway's external IP address, but without 
changing the source port address. 
[0044] In Rgure 6. rows 5 - 16 show the six standard 
ISAKMP "handshaking" datagram exchanges neces- 
25 sary to estat>llsh SAs (Security Associations) to support 
fuUy encrypted arxj authentk^ated datagrams. Although 
some modes of ISAKMP use fewer exchanges, the main 
mode is depk:ted in Rgure 6. FoHowing the establishing 
of SAs, the local computer and the target begin commu- 
te nicating using ESP protocol encrypted datagrams. 
Here, datagram valklity is maintained through the use 
of Security Parameter Indexing - SPI - numbers in an 
SPI field of the datagram's header. Each host recogniz- 
es a datagram "addressed" to its SPI, which can be 
35 modified during a session by mutual agreement of the 
hosts as necessary to ensure continued security. Wh^ 
an encrypted datagram passes ttirough the gateway, as 
depkrted at Rgure 6. rows 1 7 and 1 8, neither the source 
nor the destination SPI is modified by ttie gateway, at- 
^ though the datagram's source IP address is translated 
to be the gateway's external IP address. 
[0045] Thus, when an encrypted datagram is received 
by the gateway, it will be signified by a datagram of type 
50 (ESP). Upon encountering that datagram type, the 
45 gateway will check the datagram's Security Parameter 
Index (SPI) to see whether that SPI is recorded in its 
internal table. If it is. the gateway will translate the dat- 
agram's source or destination IP address, as appropri- 
ate, and will send the datagram to the LAN or the inter- 
so riet, depending upon the direction of transmission. How- 
ever, if the SPI of a datagram from the LAN does not 
appear in the gateway's internal table, and the source 
and destination are recognized IP addresses, the gate- 
way will assume that a new session has been started. 
55 In this case, it will pass the datagram to the extemal net- 
wori( leaving the new SPI intact, but recording the new 
SPI in the "SPI-out" field of its intemal table and placing 
a ZOT into the "^Pl-in" fieW. At rows 25 and 26 it may 



8 



15 



EP 1 130 846 A2 



16 



be seen that a new SPI has appeared, stgnrfytng a new 
session. This event corresponds to figure 5b. where the 
"0" in the "SPMn" field corresponds to the new SPI-out 
of *14662." At rows 27 and 28. the reply packet from the 
external network shows that "dd* SPI "9802" has been 
replaced with "new" SPI "3288." 
[0048] Rgure 7 Is scmtlar to Rgune 6, except that it 
illustrates the passage through the gateway of this in- 
vention of datagranis t)etwe^ three computers on a 
LAN, designated L-1, L-2, and L-3, and three targets on 
the internet having unk|ue gkitsal IP addresses, T-1 , T- 
2 and T-3, In Rgure 4. for ease of refwence, a table 
containing the IP addresses of these devices is given. 
As shown in Rgure 7, a transmisskOT designated "L-1 
Out" represents a transmissk>n from local computer L- 
1 to the gateway. *T-1 tn" represents a transmissnn from 
the gateway to target T-1 . "T-1 Our represents a tnans- 
missk}n from target T-1 to the gateway, while "L-l In" 
represents a transmisskin from the gateway to compu- 
ter L-1. 

[0047] As shown in rows 1-8 of Rgure 7, computers 
L-1 and L-2 conduct "in the dear^ communications with 
targets T-1 aruJ T-2. At row 9. L-1 commences an 
ISAKMP session with T-1. Rows 9-14 show the first 
three messages exchanged between L-1 and T-1 during 
the ISAKMP protoccrf. At row 15, computer L-3 com- 
mences an ISAKMP- 1 message exchange with T-3. 
However, at that time Port 500 is bound to L-1 and is 
associated with the IP address of T-1, awaiting an 
ISAKMP-4 reply from T-1 . In this situation, the datagram 
from L-3 cannot bind Port 500. and its source port ad- 
dress will be translated. As such, L-3 cannot complete 
the transmission that was started at row 1 5. 
[0048] Thereafter, at rows 17-18, T-Vs r^y 
{ISAKMP-4) is received at the gateway and sent to L-1 , 
and PcMt 500 immediately becomes availat)le. Thus, 
when L-3 reattempts its ISAKMP- 1 transmission at row 
19, the transmissk)n is successful. 
[0049] At rows 19-20 of Rgure 7, L-3's ISAKMP-1 
transmission twnds Port 500 to L-3's IP address. Thus, 
when L-1 attempts its ISAKMP-5 transmission, at rows 
21-22. Port 500 is not availat>le, and the gateway simply 
translates the destinatwn port address from Port 500 to 
an "arbitrary" port numt)er - in this case, "9063" - and 
sends the datagram to the internet where target T-1 will 
not recognize it as an ISAKMP datagram. However, af- 
ter L-3 releases Port 500, at rows 23-24, L-Vs next at- 
tempt to send its ISAKMP-5 1ransmissk)n is successfully 
received by T-1 . However, T-Vs reply is skw, and, at 
row 27, Port 500 is released from its binding to L-1 , and, 
at rows 28-29, is immediately grabt)ed by L-3 for an 
ISAKMP-3 transmisston. Thus, when T-1's ISAKMP-6 
reply arrives at the gateway, as is shown at rows 30 ar^ 
31 , Port 500 is blocked, and the datagram is ignored. 
Thereafter, L-1, rwt having received a reply to its 
ISAKMP-5 message, retransmits it at rows 34-35, and 
a reply from T-1 is received at rows 36-37. Foltowing 
their ISAKMP handshaking, L-1 and T-1 can communi- 



cate securely, using ESP protocol at rows 38-39 and 
42^. 

[0050] Rows 38-57 of Rgwe 7 demonstrate the gate- 
way's handBng of a variety of datagrams between a 

5 number of local computers and targets. UDP datagrams 
are shown at rows 40-41 , ESP datagrams at rows 42-43 
and 52-53, and ISAKMP <^tagrams at rows 4445. 
WWIe the chart of Rgure 7 shows diff^ent IP addresses 
for each device, in practice it may occur that a number 

10 of processes wiH be running on the same device. The 
sutTstitution of unique source ports by the gateway, and 
the use of SPPs to differentiate encrypted transn>issk}ns 
ensures that datagrams emanating from multiple proc- 
esses running on a single machine will not be misdirect- 

15 ed. 

[0051] Rgure 8 defects the irdtiatnn and transfer of 
signals between the datagram processing drcuitry 100 
and the timer 110. Upon the occurrence of an event re- 
quiring a port address to be bound to an IP address, a 

20 signal 1 20 will be sent to the timer to commence timing. 
Upon the expiration of the appropriate interval, the timer 
will send a signal 140 indicating that time has expired, 
in whk^h case any port that is bound will be released. In 
the interim, if an expected datagram has arrived, and a 

25 previously bound port is to be released, a disabling sig- 
nal 1 30 will be sent to ttie timer indrcating that ttie timer 
should be reset to await the next signal to begin timing. 
Obviously, there are numerous tinting circuits known in 
the art, and the spectfk; configuralron shown in Rgure 8 

30 Is only one of many possit>le emtxxliments. 

[0052] From the foregoing it will be understood by 
those of skill in ttie art that ttie prefen^ embodiment 
described herein is not ttie only means for practicing the 
invention, and that other embodiments may be chosen 

35 to practice the invention without departing from the spirit 
and scope of ttie invention. For example, although the 
preferred embodiment is described with reference to 
Port 500, which has been reserved exclusively for use 
witti ttie ISAKMP fWDtocol, ttie inventwn may be em- 

^ pkjyed in the same manner for processing datagrams 
destined for other port addresses that may In ttie future 
t>e assigned to other processes or protocols. In particu- 
lar, many games played over ttie internet require the use 
of specific ports on local and external machines ttiat 

45 cannot wittistand normal address translation. Addition- 
ally, alttiough the inventton has been described primarily 
with respect to communications between a private LAN 
and the internet it will be apparent that ttie gateway of 
this invention can be used at any interface between two 

so networics and will have ttie same functionality as has 
been described. 

[00S3] The claims appended hereto are meant to cov- 
er modifications and changes within the spirit and scope 
of the present invention. 

55 
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Claims 

1 . A network address translating gateway connecting 
a LAN to an external networK said LAN using local 
IP addresses, said gateway having a k}cal IP ad- 5 
dress that can be seen by device on said LAN and 
having an external IP address that can be seen by 
devices on said external network, said gateway 
comprising 

10 

a pturattty of internal tat)les associating cc^bi- 
nations of local IP addresses of k)cal devices 
on saki LAN. external IP addresses of extennal 
devices on sakl external network, SPWn val- 
ues. SPI-Out values, source port addresses. « 
destinatron port addresses, reserved port ad- 
dresses, and maintaining a list of reserved port 
addresses. 

means for performing normal address transla- 
tion upon datagrams passing from said LAN to 20 
said external netwc^ and datagrams passing 
from said external network to said IAN. 
means for d^ivering a datagram from a local 
device on sakJ I^N to an extemal device on 
said extemal network by receiving a datagram 2S 
from a local devk:e on said LAN Intended for 
delivery to an extemal device on said extemal 
rietwork, and detemiining whether said data- 
gram is encrypted arwl, if saki datagram is er>- 
crypted, for determining whether the SPI of said 30 
datagram is recorded in the SPI-Out field in 
said internal table and. if saki SPI is recorded 
in said SPI-Out fieW, modifying the source IP 
address of said datagram to be said external IP 
address of said gateway and passing saki da- 35 
tagram to said extemal r)etwork for routing and 
delivery to said extemal devk:e. 
and if said SPI is not recorded in said SPI-Out 
field of said internal tat)le, setting the SPI-ln 
field corresponding to the local IP address of ^ 
said local device equal to zero and setting said 
SPI-Out fi^d equal to saki SPI. modifying said 
source IP address of saki datagram to be said 
extmal IP address of sakJ gateway and pass- 
ing said datagram to saki extemal network few <5 
routing and delivery to said extemal device, 
and if said datagram is not encrypted, determin- 
ing whether the destinatbn port address for 
said datagram ts induded in said list of reserved 
port addresses and. if sakJ destinat»n port ad* so 
dress is not irK:luded in said list of reserved port 
addresses, performing nomnal address transla- 
tion upon saki datagram and passing said dat- 
agram to said extemal network for routing and 
delivery to said extemal device, ^ 
and if said destination pari address is induded 
in saki list of resent port addresses, deter- 
mining whether saki destinatksn pert address is 



bouTKl to said local IP address of said local de- 
vice, and if saki destinatkm port address is 
bound to said local IP address, peforming r>or- 
mal address translatkm upon said datagram 
and passing said datagram to said extemal net- 
work for routing ai^ ddivery to said external 
device. 

and if saki destinatron port address is rtoi bound 
to saki local IP address of said bcal devk». 
modifying saki source IP address of said data- 
gram to be saki extemal IP address of said 
gateway, biruiing saki destination port address 
to said k>cal IP address of said local device and 
creating an association between saki destina- 
tion port address and the external IP address 
of saki extemal devk^e. and passing saki data- 
gram to saki extOTial network for routing and 
ddlvery to saki extemal devrce, 
means for delivering a datagram from said ex- 
ternal devrce to saki local device by receiving 
a datagram from sad extemal device on said 
extemal network intended for deltv^ to said 
local device on saki LAN, 
determining whether said datagram is encrypt- 
ed and. if saki datagram is encrypted, determin- 
ing whethe* the datagram's SPI is recorded in 
said SPI-ln fieki of saki internal table and. if said 
SPI is recorded in saki SPI-ln fieki. modifying 
tiie destination IP address of said datagram to 
be said bcal IP address of said local device and 
passing said datagram to saki LAN for routing 
and delivery to saki kx:al device, 
and if said SPI is not recorded in said SPI-ln 
fieki of said intOTial table, determining whether 
saki SPI -In field conresponding to said IP ad- 
dress of saki extemal devk:e is equal to zero 
and, if said SPWn fieki is not equal to zero, dis- 
cardir^g said datagram, 

and if said SPI-ln field is equal to zero, setting 
said SPI-ln field equal to said SPI, modifying 
the destination IP address of said datagram to 
be said k>cat IP address of said k>cal device and 
passing said datagram to said LAN for delivery 
to said kx:al device, 

and if said datagram is not encrypted, determin- 
ing whettier the destination port address for 
said datagram is induded in said list of reserved 
port addresses and, if said destination port ad- 
dress is not included in said list of reserved port 
addresses, performing normal address transla- 
tion upon saki datagram and passing said dat- 
agram to saki LAN for delivery to said local de- 
vice. 

and rf saki destination port address is induded 
in saki list of resent port addresses, deter- 
mining whettier said destination pofX address is 
bouTKi to the kx^al IP address of said local de- 
vice, if said destination port address is not 
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bound to said local IP address, discarding said 
datagram, 

and if said destination port address is bound to 
said iocai IP address, modifying said destir^ 
tion IP address of said datagram to be said local s 
IP address of said local device, unt»ndtng said 
destination port address from said local IP ad- 
dress, and passing said datagram to said LAN 
for delivery to said local device. 

10 

2. The network address translating gateway of daim 
1 . furth«- comprising a timer, whwein, upon recdv- 
Ing a signal that a port address has become bound 
to an IP address, said timer will comm^ice timing 

for a predetermined length of time and. upon the '5 
expiration of said predetermined length of time, will 
send a signal causing said port address to become 
unbound firom said IP address, and, upon receiving 
a signal iruiicating that said port address has t^e- 
come untKHind from said IP address prior to the ex- 20 
piration of said predetermined length of time, said 
timer will stop timing and will reset 

3. The network address translating gateway of daim 

1 in which said external network is the internet 25 

4. The network address trar^lating gateway of daim 
3 in which said LAN is a virtual private network. 

5. A method of processing IP datagrams from a local 30 
device on a LAN using local tP addresses through 

a network translating gateway to an external devk» 
on an external network comprising the steps of 

6. 

maintaining a plurality of tables assodating lo- 35 
cal IP addresses of k>cal devices on said LAN, 
external IP addresses of external devrces on 
sakj external network, port addresses of said 
local devices, port addresses of said external 
devices, SPNn values, SPI-out values, and re- ^ 
served port addresses, and a list of reserved 
port addresses, 

receiving a datagram from said LAN 
determining whether said datagram is encrypt- 
ed arKj, if said datagram is encrypted, determin- 4S 
ing whether the SPI in said datagram is record- 
ed in the SPI-out field of one of said plurality of 
internal tables and. if said SPI is recorded in 
said SPI-out fiekJ of saki internal table, modify- 
ing the source IP address to be the external IP so 
address of said gateway and passing sakJ da- 
tagram to sakl external network for routing and 
delivery to sakl external devk^e, 
and if said SPI is not recorded in sakl SPI-out 
fieW of said internal table, setting sakl SPI-out 55 
fiekJ corresfKjnding to the IP address of said ex- 
ternal device equal to sakf SPI and setting the 
SPMn fieW of sakl internal table to zero, modn 




20 



fying said source IP address to be said external 
IP address of sakl gateway, and passing said 
datagram to sakl external networic for routing 
and delivery to sakl external devk:e. 
and if said datagram is not encrypted, detemiin- 
ing whether the destinatk)n port address for 
sakl datagram is IrK^tuded in sakl tat}le of re- 
served pc^ addresses and, if sakl destination 
port address is not included in sakl table of re- 
served port addresses, performing normal ad- 
dress translation upon said datagram and 
passing sakl datagram to sakl external network 
for routing and delivery to sakl external device, 
and if sakl destinatkxi port address is induded 
in said table of reserved port addresses, deter- 
mining whether said destination port address is 
bound to an IP address, and if said destination 
port is bound to an IP address, performing nor- 
mal address translation upon sakl datagram 
and passing said datagram to sakl external net- 
work for routing and delivery to said external 
device, 

and rf said destination port address i s not bound 
to an IP address, modifying sakl source IP ad- 
dress to be said external IP address for said 
external device, birvling said destination port 
address to the local IP address of said local de- 
vice and creating an association between said 
destinatkKi port address and sakl external IP 
address of said external device, and passir>g 
sakl datagram to sakl external network for rout- 
ing and delivery to said external device. 

A method of processir>g IP datagrams from an ex- 
ternal devk^e on an external network through a net- 
work translating gateway to a k>cal devk:e on a LAN 
using local IP addresses, comprising the steps of 

maintaining a pkiraHty of tables assodating lo- 
cal IP addresses of kxal devices on said LAN. 
external IP addresses of external devk^es on 
sakl external network, port addresses of said 
k>cal devices, port addresses of said external 
devices, SPI-in values, SPI-out values, and re- 
served port addresses, and a list of reserved 
port addresses. 

receiving a datagram from said extemal net- 
work 

determining whether sakl datagram is encrypt- 
ed and, if sakl datagram is encrypted, detwmin- 
ing whether ttie SPI in sakl datagram is record- 
ed in the SPI-in field of one of said plurality of 
internal tables and, if said SPI is recorded in 
sakl SPMn fiekl of said internal table, modifying 
the destination IP address to be the internal IP 
address of said kxal device and passing said 
datagram to sakl LAN for routing and delivery 
to sakl local device. 
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and if said SPI is not recorded in said SPMn 
fidd of said internal table, detennining whether 
said SPMn field correspomiing to the IP ad- 
dress of said external device is zero, and rf said 
SPMn field is not zero, discarding said data- 
gram, 

and tf said SPMn field is equal to zero, modify- 
ing said SPMn field to be said SPI. modifying 
said destination IP address to be said local IP 
address of said local device, and passing said 
datagram to said LAN for routing and detivery 
to said local device. 

and if said datagram is not encrypted, determirv 
ing whether the destination port address for 
said datagram is Included in said list of reserved 
port addresses, and if said destination port ad- 
dress is not included in said list of reserved port 
addresses, performing normal address transla- 
tion and passing said datagram to said LAN for 
routing and delivery to said local device, 
and if said destination port address Is included 
in said list of reserved port addresses, deter- 
mining whether said destination port address is 
bound to said local IP address, arrd rf said des- 
tination port is not bound to said local IP ad- 
dress, discarding said datagram, 
and rf said destination port address is bound to 
said local IP address, modifying said destina- 
tion IP address to t>e said local IP address of 
said local device, unbinding said destination 
port address from said local IP address, and 
passing said datagram to said LAN for routing 
and delivery to said local device. 



9. The method of pHt>cessing I P datagrams as daimed 
in daim 5, in which said external network is the in- 
ternet. 

5 10. The method of processing IP datagrams as claimed 
in daim 6, in which said external network is the in- 
ternet. 

11. The method of processirtg IP datagrams as daimed 
10 in daim 5 in whk:h said LAN is a virtual private net- 
work. 

12. The method of processing IP datagrams as daimed 
in daim 6 in which sakl LAN is a virtual private net- 

15 work. 
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30 



7. The method of processing IP datagrams as daimed 35 
in daim 5. further comprising the steps of startir^ a 
timer whenever said destination port address be- 
comes bound to said local IP address of said local 
device, 

40 

resettling said timer whenever said destination 
port address has become released, 
and sending a signal whenever said timer is ac- 
tive and a predetermined length of time has ex- 
pired from the time said timer was started. 45 



8. The method of processing IP datagrams as claimed 
in daim 6, further comprising the steps of starting a 
timer whenever said destination port address be- 
comes bound to said local IP address of said local so 
device, 



resettling said timer wher»ever said destination 
port address has t>ecome released, 
and sending a signal whenever sakj ti mer is ac- 55 
tive and a predetermined length of time has ex- 
pired frwn the time said timer was started. 
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